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Ex cutive Summary 



This document describes the anticipated infrastructure for the deployment of the Electronic Music 
Distribution (EMD). It deals primarily with technical and operational aspects of the EMD: business, 
marketing, customer and competitive issues are addressed elsewhere. 

This document establishes the EMD's high-level requirements, functional and architectural elements and 
environment. The detailed designs and requirements and specific implementation issues are addressed in 
lower-level documents. 

The supporting EMD architecture should be adaptable, reconfigurable, scalable and offer High quality of 
service to the users. It should also be open in allowing other distributors to join the system, friendly to use, 
make it easy to find the musical content, protect intellectual property rights and commercial business rules 
while allowing complex business models, support a wide variety of information appliances, provide 
multiple payment options, gracefully maintain service quality during peak demand, andlprovide on-going 
compatibility of supporting "legacy" content and players. 



,4" ^ xr 



The proposed high-level architecture consists of seven modules:;Production •Systems, Content Catalog, 
Reference Service, Delivery Service, Retail Web Sites, Consume^Device, Electronic Clearinghouses. This 
modular design was selected to allow various market participants (e.|., distributorspetailers, CE 
manufacturers) to maintain their business identity and; to build their own modules within the specified 
interfaces, while ensuring that any module or device build in accordance%ith the specifications will be able 
to interact with the rest of the system. |ft V' 



The EMD system will utilize accepted international standards and technologies, such as X.509 for 
authentication, SSL for secure sessions, E)ES and triple®^ Jfor block encryption, RSA for public key 
encryption, TCP/IP, HTTP, FTP and SMt^fcr%ans X.500 for directories, ASN.l 

for naming syntax, etc. The EMD Content Distribution Formats will be defined to specifically meet the 
music industry's needs. : K . "I s ^ 

The deployment requirements are broken: into tHree ^ phases: | 

The pilot implementation described in 
Appendix, together with the effqrt and cost ;esti mates. 
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Electronic Music Distribution (EMD) System Requirements 



This document describes the anticipated infrastructure for the deployment of the Electronic Music 
Distribution (EMD). The "EMD infrastructure" is defined as a collection of hardware, system and 
applications software, networks, operational processes, standards and technologies, protocols, data formats 
- all the elements essential to delivering the end-to-end EMD service. This is a high-level document (the 
"top" of the technical documentation tree) establishing the EMD's high-level requirements, functional and 
architectural elements and environment. The detailed designs and requirements and specific 
implementation issues are addressed in lower-level documents. 

The supporting EMD architecture should meet the "generic" design requirements typical of corriplex 
electronic systems. In addition to that, it should meet the requirements specific tojhe EMD applications. 

The "generic" long-term design requirements include: /'/ ^ pj 

openness and adaptability to change. The system should^notbe ^bverly'dependbnt on any given 
vendor or technology. This requires adoption of internalional standards over proprietary 
technologies, abstracting applications from the under! ying v platforms and architecting the 
infrastructure in a modular fashion as a collectipn v df autonomous services and systems with well- 
defined interfaces. When proprietary protocols have to be used, they should be encapsulated into 
standard structures. The messages should/carry sufficient information to identify how they should 
be processed < \ 

reconfigurability. The system should be designed to handle both short-term changes and medium- 
to-long term evolution in a transparent fashion;^vithout disrupting the service. It should be 
possible to add new features with relative ease arid at a reasonable cost 

high quality of service. The system' should meet performance requirements of fast and consistent 
response to interactions. The system should be. manageable, reliable and available in a "7 X 24" 
fashion. There should be no single point/of feiiu|e'fcr the entire system. The system should 
employ a highly automated backup/restore strategy 

scalability. The system should allow for an> economic implementation where the system resources 
are deployed as they are needed. \This calls for a highly scalable design, sized up for the initial 
deployment but capable of expanding by simply adding new elements (e.g., servers, storage) 
without disrupting the existing operation. For scaling to be effective, all system components - 
hardware, platformsv^ operating systems, middleware, applications, I/O devices - must be able to 
scale up to aceommodate;pthers 

practicality. The system should be designed around the reality of the evolving public 
telecqmmunications^and^security infrastructures, using commercial-of-the shelf (COTS) 
^ \ technologies and standard integration and data tools whenever possible 



To support the specific EMD applications, as driven by the anticipated business model and deployment 
plans, the infrastructure should: 

allow other distributors (besides UMG) to "join" the system. This requires clear definition of the 
interfaces, non-preferential treatment of the distributors and protection of sensitive information, 
adoption of global naming conventions, etc. The infrastructure should make the right trade-off 
between establishing mandatory common elements for cost-effective implementation of user 
devices while allowing various parties involved to implement their own systems and to protect 
their business models and business data 

provide a user- friendly mechanism for acquiring enabling applications software (e.g., 
downloading the EMD "player") 

make it easy to find the content. Allow searches both by attributes and by classification 



be able to authenticate, to secure information and to support and enforce commercial rules and 
intellectual property rights. Support flexible business arrangements and sophisticated rights 
management, including multi-party offers, complex distribution chains, superdistribution, 
discounts, pay-per-use, copying and loaning, creation of derivative works, etc. 
allow for a wide variety of information appliances to attach to the infrastructure. The system 
should support both PC and consumer electronics (CE) platforms, different levels of connectivity 
(always connected, occasionally connected, never connected), fixed location and nomadic usage, 
downloadable and pre-packaged media, etc. 

provide and enforce easy, intuitive and consistent naming conventions 

be coordinated with the current UMG business processes and with the evolving UMG business 
support systems. EMD infrastructure should lend itself to automation of internal business 
activities />/ v • s - 

protect music from piracy and illegal access while keeping these measures within the envelope of 
a cost-effective CE implementation vrt 
support multiple payment options. Provide financial and usage reporting x V\ <v/ 
allow for the content to be delivered completely and without/errors (the. timing of the delivery 
must be reasonable but might not be as critical) \ x - \ ■ \ : '/ 

allow for the information to be retrieved quickly < j '* ^- \; ,( \\ /y 

support real-time processing of customer requests via transaction monitoring arid' workload 
balancing schemes v-V \/ Y v 

adhere to regulatory environment. The EMp.arehrtecture must consider ^the global implications of 
data collection, storage, processing, use and' distribution. Thiols: particularly true for user data and 
financial settlements where privacy and taxation laws vary widely; : ; 

the reality of the music business is that 1) a'small portion of the content usually generates the 
majority of the demand, and 2) "hits" or promotions can generate significant but temporary 
"spikes" in demand. Thus, the infrastructure should be designed to accommodate demand 
variations. This would require l) v a. highly distributed architecture where the content is stored in 
multiple places close to the end users, v and 2) ability to send the content to multiple users at the 
same time. This in turn, requires content replication and synchronization and multicasting 
communications techniques/ v \/ i/ 

■■:'-< ^ 

In the definition of the EMD system there will be ; differences between short-term and long-term goals. 
Not all of the above requirements need to be met in the initial "proof-of-concept" implementation. Instead, 
the approach will iterative: "try it" based on a rapid application development, test with the users and other 
parties, and modify based on the stakeholder feedback. One example of this approach is integration of the 
EMD system with the rest of Uni versal ! s business systems. In the long run it is desirable to "seamlessly" 
integrate EMD with the 'other processes and systems, e.g., where business affairs and legal negotiate for the 
EMD rights as a : part of their regular negotiation "routine", EMD releases are planned as a part of regular 
release planning- EMD's digital asset management is a part of the overall company- wide asset 
management, etCv Ho we vermin the short term, the goal is to implement the EMD as a stand-alone operation 
with well-defined links to the "regular" processes and systems (e.g., the same people who obtain traditional 
distribution rights will obtain electronic distribution rights, etc.) while laying out a migration path to the 
long-term goal. 

Another critical aspect of the long-term EMD implementation is the required on-going compatibility 
between the content and the players. As the EMD system becomes operational, it will create a population 
of the "legacy data" (content) and the "legacy applications" (players). In the connected, "PC world" it is 
acceptable to expect that the users will periodically upgrade their applications; the new applications rely on 
the increased memory, storage and processing power to be able to process "legacy" data formats, while the 
old applications usually can't process the "new" data formats. In the off-line, "CE world" changes in 
formats are much more expensive and operationally difficult and should happen with much less frequency. 
The hardware resources in the "CE world" are also limited, making it more difficult for the applications to 
process multiple formats. 



A fully commercial EMD system must address these issues with the objective to 1) minimize situations 
where players are not compatible with some of the content and vice versa, and 2) design into the system 
operational processes for replacing or upgrading "legacy" players and content for both on-line and off-line 
devices. Although the on-going compatibility will not be required in the early stages of the EMD, there 
will be a time-point where it becomes a requirement to determine a suitable strategy for the upgrading of 
content and the players. In the immediate deployment of CE devises, they may be restricted to only playing 
fully paid content based on a reduced set of rights (as with current media), using such schemes as CSS2. 



High-L v I Conceptual Architecture 




Architectural Components 

The provision of an EMD architecture has four essential elements of focus: 

management of the digital assets 
secure delivery of the content 
finding the content 

tracking of usage and provision of financial settlements 



These elements are instantiated in the form of seven modules as illustrated in Diagram^ below, these 
modules comprise the high-level functional architecture of the EMD^service fof\the PC platform: Each of 
the architectural modules is defined to perform a specific set of related v functions while communicating with 
other modules through specified standard interfaces. The definition of these] interfaces enables the overall 
development to be broken down into manageable parallel development of theMndi .vidual; modules. The 
modules will be defined such that multiple implementations (of each^of the modules can be supported within 
the standard interfaces. J V ''\X K 0\\ W 



Use and pay 




Content mid offers 



Diagram 1. High-Level Functional Architecture for PC Platform 

Each of the seven modules is defined below: 



• Production Systems perform largely back-office tasks of populating the EMD service with content and 
associated commercial offers (rights). 

• Retail Web Sites are the "regular" web sites of the music retailers who signed up for the EMD service. 
They provide retail com mercial offers (rights) for the EMD content and can be accessed by consumers 

regular browsers ^^^^^^HM^^^^^^^HI^^^fl 

• Content Catalog is a combination of "White" and "Yellow Pages" for the EMD content. It is 
optimized for quickly finding the content based on a constrained set of attributes and can be accessed 
only via a specialized "player". 

• Reference Service helps customers to purchase the content by linking it with valid commercial offers. 

• Delivery Service downloads the actual content and associated rights to consumer devices. 

• Electronic Clearinghouse Services manage the actual purchasing process by paymentlprocessing and 
collecting usage and survey information. /'\ \M\ 

• "Consumer Device with the EMD Player" enables customers to interact with the system, tdtdpwnload, 
store, purchase and consume the content while enforcing the business rules. ffl 

Summary of Systems Operations K ^Q;ff K \ J 7 

The combination of these modules and the relationships and between the interfac^^^form the basis for the 
overall operation of the EMD system. The high level procesMor creation and consumption of the content is 
outlined below. 4'"' ^ 

Iff, ^>:* 

The Production Service will prepare content for electronic distribution by packaging content and associated 
rights into defined secure containers. The Retailers^*}} add, or have added on their behalf, their 
commercial business rules, usually a margin, for the consumption of the content. The resulting content 
objects will be "staged" in the distribution|mfrastructure TOrJddiy&ry via the Delivery Service. The 
Retailers will place the offer description arid the appropriate HTML reference on their web sites for access 
by the consumer. The Content Catalog will ha ve, the content^ obj ect description in its directory whilst the 
Reference Service will have description of the'content, ^associated rights and retail references in its 
directories. The Delivery Service will have the actual content objects and their encapsulated rights in its 
databases. %f 

4k '^Itk '%■■ ? 

The consumer whcf has downloaded and activated the specialized EMD software (the "player" including 
the Rights Management Software or RMS) on finding an offer at a retail web site, will select the offer by 
"clicking" on it. TrJis^villStf ansparentlpmessage the Reference Service to validate the offer and, subsequent 
to the validation, the Reference Service will instruct the Delivery Service to commence the download of the 
content and encapsulated to the user's "player". When the user consumes the content, its player will 
interactwith the Rights Mariagement Software and with the appropriate Electronic Clearinghouse Service 
to enable the transaction. THle user can also get the content by searching the Content Catalog using the 
player "find" functionfifbm another user (superdistribution) or by acquiring it on a portable media (e.g., a 
DVD disk) via<a:physical retail outlet. The distribution methods can be different for different platforms. 
For example, unconnected CE players will only be able to process content on a portable media with the 
rights which don't require electronic connectivity. 



Multiple Distributors 

The initial deployment of the EMD system is envisaged as having a single distributor, though the 
architecture of the EMD system must be able to support a number of suppliers of content and well as a 
diverse range of consumption methods and models. Diagram 2 illustrates how the EMD service can be 



implemented with two service providers (e.g., distributors). This is extensible to support the current 
industry and future industry growth and diversity. 




Use and pay 



Diagram 2. Illustrative EMD Service Architecture with Two Distributors 



The two service providers shown in the (diagram ^Distributor A and Distributor B - each have their own 
Production Systems,. Reference Services ahd^Delivery Services. The Content Catalog is common to both 
providers (i.e., it has information kbout available EMD content from both Distributor A and Distributor B). 
Each of the twp retailers shown - Retailer /1/and Retailer 2 - signed up with both distributors and offers 
content from Both. T wo,electronic clearinghouses are shown, one for each distributor. The structure is 
transparent to the consumer for wftonrthe process of finding, retrieving and purchasing electronic content 
is the same whether the offered content originated with Distributor A, Distributor B or even a combination 
of both. Additional distributbrs/can be added to the architecture in a modular fashion. Different 
arrangements are possible and can be negotiated between distributors, e.g., Distributor C may have its own 
Production Systems and Reference Service but purchase delivery services from Distributor A. 
Implementation of the modules is left to service providers subject to a set of rules designed to ensure 
i nteroperab i 1 i ty : \ > , - : 



service provider has to comply with the specified information model to enable proper operation of 
the consumer media player 

service provider has to comply with the minimum mandated set of the security and Intellectual 
Property (IP) protection requirements 

the Delivery Service has to comply with the appropriate player's interface to ensure that content is 

downloaded and processed in an identical fashion regardless of its origination 

service provider has to supply information about its content to the Content Catalog in a specified 

format and support information synchronization between the Content Catalog and its Reference 

Service 



service provider has to support information exchange between Reference Services in a specified 
format to enable retail offers which aggregate content from multiple distributors 
electronic clearinghouses have to comply with the appropriate media player's interfaces to ensure 
that the content's usage and payment information is processed in an identical fashion. Electronic 
clearinghouses may be required to exchange the EMD-related information (e.g., to enable retail 
offers which aggregate content from multiple distributors). 



Enabling Standards and Technologies 



The deployment of a successful EMD strategy will involve a number of standards and technologies. This 
section provides some high-level guidelines for the more important standards and technologies which are 
anticipated for usage in the EMD system. 



Security 



The EMD system has to protect both the Intellectual Property (IP) content and the rightsjgoyerning 
transactions for that content. There are a number of enabling technologies and measures which: can be 
applied to securing electronic commerce. The EMD system specifications shall- provide the framework and 
the policy for implementing security measures within which different technolpgies^can be used as|| 
necessary. A trade-off must be achieved between providing enough security to sufficiently protect music 
from piracy and illegal access while keeping the overall system user-friendly arid i mp lemehtab lejat a 
reasonable cost. For example, it is anticipated that all the rights information will^Be, encrypted? but only 
some of the actual music content (enough to make it "unusable")! Tlie details pf this trade-off will be 
continuously evaluated and iterated as we progress through design and testingiplns anticipated that the 
EMD participants (i.e., the distributors) will have to complyfwith ^ common sefo|security technologies to 
keep the complexity of user devices at a reasonable leyeb * ; ^t ? |, Jx 

Some of the security mechanisms anticipated in thefEMD include: '* : vgv y 

cryptographically secured message structures:^ \ 

protected storage and processing . M 

authentication schemes (certificafes;§ignature key systems) 

physical security measures (e.g., passwords), 

watermarking of the content t| - 

transactional watermarking ; ^ ^ # 

tamper-resistance * %, 

The EMD security policy may include the following (as an example): 

production systems protected by firewalls, passwords, etc. 

all intellectual property content outside of the production systems (i.e., on the internet) is 
cryptographicaily secured^. 
,i all messages involving movement of financial information or intellectual property are 
- cryptographicaily secured 

cryptpgraphic key system with periodic key changes 

changes/up^aHes of the rights management software 
all the EMD clients must be authenticated for every financial transaction 
all the EMD clients allowed to download content must have protected storage and processing 
mechanisms- 
certification of the interfacing applications and limitations on the interaction with non-certified 
applications software 

rights management software and hardware is tamper-resistant 
all the content is watermarked. 



Examples of the standards and technologies which will be considered for inclusion in the EMD are: 



For more detailed discussion please see EMD Documents 1.1.1, 1.2, 1.3.1, 1.3.3, 1.4.3. 
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Transactions and Payments 



rf 

is? 



The EMD system' will no^mandate^y single electronic transaction and payment system. Instead, the 
details of the transact will be abstracted out of the system. Any 

clearinghojuse^wishiri^^participate in the EMD will have to comply with the information formats and the 
reporting ahd^security reqyirementsf Clearinghouses will be required to support multiple electronic 
payment mechanisms, such<as online credit card payment, HmiB' etc - Transaction 
a gg r cg^ t ipj^.^.)l a nisms need to be supported. 

For more detailed, discussion please see EMD Documents 1.5.1 and 1.5.2. 



Transport and Communication 



For data transport and communication the EMD system will utilize the existing internet standards, such as 
TCP/IP, FTP, HTTP, SMTP, etc. Any specialized or proprietary data structures will be encapsulated 
within these standard protocols. 



For more detailed discussion please see EMD Documents 1.1.1, 1.2. 



Naming Services and Directories 



It is mandatory that in order to achieve interoperability the EMD participants will adhere to the agreed- 
upon global naming conventions. The current music industry ID tags (e.g., the ISRC codes) are not 
sufficient to meet the EMD requirements. While there are some developments in creating object 
identification systems in other industries (e.g., DOI for publishing), presently there is no standard global 
naming convention for the music industry. The EMD system will require an attribute-based name service 
capable of resolving both precisely known object names and imprecise queries. The EMD system will also 
require that the information be organized in directories in a way that allows fast search performance, 
provides storage integrity, scaleability, replication and access control. , 

It is proposed that the EMD use the X.500 Directory Service - defined by the CGITT and IS(i standards 
organizations as an Application Level service in the Open Systems InterconnectibnXOSI) set of standards - 
to meet these requirements. The EMD's X.500-based Directory Information Base (DIB) will be organized 
in a tree structure with named nodes and a range of content attributes stored at each nodeo All objects will 
be classified by type defined according to the ASN.l syntax notation:' The objecl^types and attributes will 
be defined specifically to match the EMD content and operations the 
EMD system to take advantage of the emerging trends in the networking arid information management 
(such as Directory-Enabled Networking (DEN), X.500 and its 7 subset LDAP) aridj leverage the standard 
integration and data tools, while creating a system custom- fit for the. EMD needsX 

s - ^ 

The X.500 directory structure will be implemented/via an industrial X.500 directory system product which 
will be overlayed over database platforms. It will be mandatory that all the'EMD-participated systems 
support X.500 or, at least, the LDAP protocol. V*\\ ^ 

\ : ;-^ ft 

The following CCITT standards will employed for the EMB.directories: 

X.501 The Directory - Models \\ " ; 

X.5 1 8 The Directqry.-rProcedures ' for'/Distributed Operation 

X.5 19 The Directory - Protocol Specification''' 

X.525 The Directory - Replication \\ 

The LDAP Specification' will have to be supported by the organizations not implementing the X.500 
protocols. j;[ \ K v :|k Jf 

\;\ /} X : v - y 
For more detailed discussion please see EMD Document 1.1.1. 

Databases' \ y 

The EMD system does not mandate database systems, products or vendors. However, it is necessary for 
distributors to choose industrial strengths solutions with high performance, reliability, scalability and 
replication capabilities. Thus, it is expected that commercial, well-proven DBMS's will be utilized. 
Furthermore, it is expected (but not mandated) that either relational or object-oriented DBMS's will be 
employed. 



For more detailed discussion please see EMD Documents 1.1.1, 1.2. 



Multimedia 



Given continual change in this industry, the EMD system has to be flexible with respect to the multimedia 
standards. Different standards and formats will be defined in object attributes, and additional ones can be 
added as needed. Since objects with encapsulated content will carry information about the content's 
format(s), a player compatible with the specified format(s) will be able to process the content. 

The activities of the MPEG 4 group will be closely monitored and the EMD system will be aligned to this 
emerging standard as it develops. 



For more detailed discussion please see EMD Documents 1.3.1, 1.4.1, 1.4.2. /^''''^^^i't 

k 

Integration Technologies 



The challenges of building a large, distributed complex information, system, sue h^as>EMD andjintegrating it 
with the existing "legacy" operations can be addressed by dividing the system; into manageable elements 
that interact to form complete applications. It is anticipated that integration of distributed components will 
be achieved via so-called "middleware" products. There are two general middleware categories - 
Transaction Processing (TP) managers and CORB A-hased Obj ect Request Brokers^ ORB) - which are 
increasingly converging. CORB A-based solutions should be evaluated Based on their compliance with the 
Object Management Group (OMG) Object Transac|ion Services definition; ^ 

%, i 

Network Management % , Jjj 

The network management tools should as a %nimuhf support Simple Network Management Protocol 
(SNMP)-compatible agents in .the various hardware and spftware components, based on a Management 
Information Base (MIB) interface definition. These will be complimented by Enterprise management 
systems that provide a method for manaiging the operation of a widely distributed system. 



D scription of Architectural Modul s 



Within the overall architecture the individual modules are outlined below. Note that the initial architecture 
is targeted towards a connected user with a PC-based platform. Other devices (e.g., an unconnected CE 
player) can be implemented as constrained subsets of the described service. 



Production Systems 



This module provides processing, labeling and packaging of the content and associatedvbusiness rules into 
the formats suitable for storage and distribution on the Internet. There can be multiple Production Systems 
modules (e.g., one for each participating distributor). The Production Systems-module will interface to the 
internal business processes and systems. Within the EMD architecture, the Production Systems will 
populate the Distribution Infrastructure (including the Content Catalog, the Reference Service, and the 
Delivery Service) with the secured content and the offers (rights) for purchasing this content. The 
Production Systems module will be protected, allowing only authprizeH^aqpess from the rest of the Internet 
(e.g., by a firewall). It is currently anticipated that only "secured" ihtellectull^Property will be allowed to 
exist outside of this module. yfr %|k '^' : X 

The Production Systems will also interface to the Retailers Web Sitesjfor providing information about the 
content availability and receiving associated retail offers. Initially, the Production Systems will also 
interface to the Electronic Clearinghouse Services for payments and usage information; eventually, this 

interface will be migrated directly into the internal Business Operations Support Systems. 

■®k % 

The Production Systems will be the part of. the EMD most directly interfacing to the other internal 
processes and systems. Combination of m^Praduction Sysferr^^rieir processes and the internal systems 
and processes involved is referred to as the'^Backr(D|fice Systems". 

For more detailed discussion pleasW see EMD Documents 1 .4, 1.4.1, 1.4.2, 1.4.3. 

Retail Web Sites J , \-*' ■ 

This will be usually be the first point of contact with the user, where they have located a retailer's web 
server and downlofded thejpage containing the reference to the content, including the retailer's purchase 
offer. Customers wil| perfbrm this operation using their Web Browsers. All actions upon selecting this 
reference wilfthen be transparent to the Retail Web Sites. The Retail sites will interface with the 
Production Systems module to receive information about available content and provide associated retail 
offers. Upon receiving the offer, the Production System module will return to the retailer's web server the 
appropriate HTML reference which will be unique to that particular offer. In the future some Retail Sites 
may elect to process aricl create the HTML references internally and communicate them back to the 
Production Systems modules. 

For more detailed discussion please see EMD Documents 1.2.1, 1.4.3.2. 



Content Catalog 



The Content Catalog module contains information about all the content available for the EMD distribution 
and "registered" with the Catalog. The Content Catalog will be "open" to all the content providers 
compliant with the applicable standards and naming conventions. The Catalog will be populated by the 
content descriptions from all the EMD-participating Production Systems. 



Consumers will query the Catalog via the "Find" function of the Universal Media Player (UMP). When 
queried, the Content Catalog will return to the consumer a list of the content matchingthesearc^ 
The operation will be similar to t he "Search" fun ction of a typical Web Browser | ^^^^^^^ 
performed on a Web catalog site H^^HH- However, instead of returning literally thousands of 
relevant entries, the Content Catalog will return a short list of the content matching the search criteria and 
available for the EMD distribution. The Catalog will not keep track of the commercial offers associated 
with the content nor of the content's storage location. Instead, each of the returned entries will refer 
customers to the appropriate Reference Service (usually associated with a distributor) which can resolve the 
reference into commercial offers and the actual content storage location(s). 

For more detailed discussion please see EMD Document 1.2.3. /^--^ v 

Reference Service \ \ 

This module resolves references to the content and the associated commercial offers. There can be' multiple 
Reference Service modules (e.g., one for each participating distributor), each handling only-the^'content and 
the offers assigned to it. This would allow distributors to maintainan effective operational control over 
packaging and purchasing of the content they distribute. The Reference ServicXmodulejreceives reference 
requests from the users, based on a reference from either 1) a Retail Web Site; org) a/esult from a Content 
Catalog search, or 3) a secured content being distributed>difectly byithe consumers (i:e., super-distribution). 
References from retailer's sites and from super-distr^utlbn-will usually identify the content and the offer 
uniquely. In this case the Reference Service will verify that the offer is\alid.and pass the content request 
to the Delivery Service module. If the offer is not yalid (e.g., it expired ©relationship with that retailer has 
been terminated), the Reference Service module will-provide the customer with valid offer(s) based on 
certain business rules. The Reference Service will function similarly when responding to a reference based 
on a Content Catalog search - since the search results wilpnot prpyide actual commercial offers, the 
Reference Service will provide the customer with commercial based on the content being requested 
and its business rules. The Reference Servic^wilHerpopulated by the descriptions of content and 
associated commercial offers andjby; the business rules'frQm'all the Production Systems assigned to that 
Reference Service (e.g., from the same^ distributorship). if 

For more detailed discussiomplease see EMD Document 1.2.2. 

Delivery Service y \ // 

This module receivesSrid. stores thl.actual secured content and offers from the associated Production 
SystemsTlt also received requests%om the Reference Service to send content to the users and delivers 
secured content to the consumers. The primary function of the Delivery Service is storage- and 
communicatipn T priented - retrieve and transmit the content quickly and without errors. 

Within this function js also the need to be able to guarantee a quality of service (QOS) to a customer. This 
allocation of service bandwidth may be based on the emerging standards such as RSVP or may involve 
premium provision in conjunction with ISP's or other bandwidth providers. As discussed later in the 
document, the Delivery Service is a logical candidate for outsourcing to an internet services provider. 

For more detailed discussion please see EMD Document 1.2.4. 

Electronic Clearinghouse Services 



These modules will provide the mechanism for the user to access the secured content by transacting for the 
appropriate rights. They will collect information on usage and transactions, which may include surveys and 



other non-financial information sets. The Clearinghouse Services will interface with the users, with retail 
sites and with the internal business systems of content providers (initially the Production Systems module). 
Interfaces to the Clearinghouse Services module will be defined using emerging electronic commerce 
standards rather than proprietary protocols, to enable usage of any clearinghouse service compliant with 
these standards. 

For more detailed discussion please see EMD Documents 1.5.1, 1.5.2. 



Content Consumer 

' * , 

,<# \ 

Content is consumed by our customers using the Universal Media Player (UMP) pr a UMP-comp x atible 
player on a suitable host, initially the Wintel PC, eventually various Consumer Electronics (CE);devices. 
The key components of the UMP are: \ \c\ V/i 

Rights Management Software (RMS) - a virtual machine that rrianages^the user- frights .to operate 
on the content * '\ ; f .-£\ \ V''/ 

Protected Rights Database (PDB) - a secure storage of ,user^cqu'tted(rights being managed by the 

rms * h v 

Content Database - a storage facility for secured acquire^ content '^^^ // 
Electronic Commerce Module (ECM) - manages user accounts, budgets;gayment history 
Controller - manages memory, media playersrassqciations, events scheduling, installation 
Editor - manages lists and associations /•• V^^^ 
Viewer GUI - manages user interface. i : \ ■/ 

V:. ; .S. 

In order to be able to download content from the EMD, the player needs to be supplemented with a 
communications device (phone modem, cable.m^ 

For more detailed discussion please see EMD Documents 1.3.1, 1.3.2, 1.3.3, 1.3.4. 

Deployment Manager \.\ \v 

The Deployment Management function is one of key elements of the supporting infrastructure. The 
Deployment Manager wiltprovide the user with the UMP, after which the user will be able to undertake 
transactions and gain access tb thexontent. The Deployment Manager will also "cancel" user's devices as 
needed to lock the "unwanted" users out of the system. 

The-beplpyment Manager wilDalso undertake the registration process of the initial clearinghouse function 
and is key element in authenticating the identity of the user and the location of any Rights Management 
Systen 

Supporting Functions 

While not shown on the architectural diagram, the EMD service needs to be supported by an operational 
infrastructure. Support will need to be provided for the EMD customers, some special UMP applications 
(e.g., e-mail, buddy list) and for developers enhancing the EMD. Network management and customer care 
facilities will be needed for the EMD operations. 



For more detailed discussion please see EMD Documents 1.6, 1.6.1, 1.6.2, 1.7. 



Data Architecture 

The EMD design will provide an environment in which the content published on the Internet can be 
leveraged into enhanced commercial and other interactions between content providers and content 
consumers. The knowledge about content, artists, users, etc., will be structured using uniform object- 
oriented modeling formalisms derived from standard specifications. 

The information model consists of a schema for defining objects and rules governing how objects interact 
with each other. It is proposed here to utilize the information modeling principles drawn from the X.500 
series of international standards. A common namespace will be promoted to ensure thatapplications 
developed by different vendors can inter-operate with each other. 

All the EMD messages should be compliant with the EMD Content Distribution Format (CDF) v described in 
the document EMD- 1.1.1. The high-level structure of the EMD mes sages; iis : Uefine1iSs^|bllows: W§ 



Field 


Content Is. 


Header 


Identifiers, object class and sub-clatss\ \.Jy' 


Signature 


Authenticates message originator^ K 


Business rules 


Business attributes pertainingffo the content 


Security-recipient 


Decryption information for individual recipients \ 


Distribution information 


Message processing information 


Content description 


Content attributes |l 


Rendition information 


Playing/media attributes #' 


Extension information 


Pointers to extension Objects 1 


Encapsulated content 


Secured content; proprietary distribution structures 
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The Header is the mandatory field for all object'classes. Other fields can be mandatory or optional 
depending on the object's class. % /f* ^--o 

The main types of object classes are: ^| k \ 



Track - a single distinct unif qf content which can be transacted upon (e.g., a song) 

Group - a combination of tracks (<b.g., an album or a collection of tracks bound together by business rules) 

Content Description - description of content attributes of a track or a group 

Business Rules - descriptioh of business attributes pertaining to a track or a group 

Rendition^ descriptioniof playing/media attributes pertaining to a track or a group. 

The infbrmati6nf (object classes) is distributed among various architectural modules as follows: 



Architectural.Modulef 


: f Information (object classes) 


Content Catalog^ 


Content Description for tracks and groups for all EMD content 


Reference Service ; y 


Content Description and Business Rules for tracks and groups for all 
content from a particular distributor; HTML references 


Delivery Service 


Tracks, Groups, Content Description, Business Rules and Renditions for all 
content from a particular distributor 


Consumer Device 


Tracks, Groups, Content Description, Business Rules and Renditions for all 
content downloaded by the particular consumer 


Retail Web Sites 


HTML references 



Objects will be bound together in secure persistent containers to form the basis of content and rights 
distribution in the EMD. For example, two tracks can be combined in the same container with a business 



rule "purchase each track for $1 or two tracks for $1.50" and the combined object can be safely (from the 
Intellectual Property perspective) distributed on the Internet. 

Information-wise, the EMD is envisioned as a Directory-Enabled Network (DEN), consisting of X.500 - 
compliant object-oriented distributed directories. This would allow fast and consistent searches across the 
entire EMD system. 

For more detailed discussion please see EMD Document 1.1.1. 
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N tworkArchit cture 



This section provides high-level networking assumptions about how the EMD system modules are 
configured (e.g., distributed vs. centralized) and interconnected. This is a strictly an architectural 
perspective not providing recommendations or solutions. 

Content Catalog 

It is currently assumed that the Content Catalog (CC) is a separate physical and logical entity providing 
directory services of available EMD content for all the participating content distributors., vjhere will be a 
single global CC for the EMD system (although its instance can be replicated as nece^ry)g^ts 
information store is formed by the participating organizations sending it contenjdescription objects. It is in 
the content providers' interest to participate in the CC as this will increase their sales. To ensure that the 
CC searches are objective (i.e., give no preference to any party), it is assumed |hat the CC will be run by a 
"trusted party" such as IFPI. It is assumed that the CC will receive its content from the Production Systems 
of the participating distributors and will synchronize its directory witmtHe, Reference Servicjjs.of those 
distributors, although other implementations are possible subject to-more detailed design considerations. 

Reference Service Mf" ''^rh. s'' 

It is assumed that a given Reference Service (RS) provide! dree tory services of available EMD content and 
associated commercial offers for one distributor onl# (i.e., each EMD-parlieipating content distributor will 
have its own RS). To improve performance, distributors may choose to replicate the instances ot their RS 
as necessary. RS's from different distributors will communicate with each other to enable retail offers 
which combine products from different distributors.' It; is assumed that this communication will be directly 
RS-to-RS (alternatively, it can be via the Content Catai6^RS : CC-RS). It is also assumed that each RS will 
receive its content from the Production System^pf the giv^ff^dMributor and will synchronize its directory 
with the Content Catalog. \ 

_ : , : -:. i : ; T:-, l: \f 
Delivery Service jp"'"' % ''''' 

A given Delivery Service (DS)will provide fulfillment function (downloading of the content and rights 
objects to the users) for one distributor only. There might be multiple DS's per distributor - e.g., one per 
label. It is assumed that to provide||he required performance each DS will be physically distributed and 
replicated across multiple locations governed by a Resource Manager. It is also assumed that each will 
receive its content from the Production Systems of the given distributor. 

Due,to|the anticipated highly : distributed nature of the DS (with server farms positioned in multiple 
locations), jt is a logical candidate for outsourcing to one of the major providers of web site hosting 
services. If the outsourcing strategy is pursued, the candidates should be evaluated on such criteria as 1) 
server farms" available in most large metro areas, 2) cost-effective services, 3) strong network operations 
capabilities with established processes and escalation procedures, backup and emergency recovery, 4) 
reliable, high-speed backbone, 5) good security measures (firewalls, monitoring, physical access), 6) 
support of different levels of performance, and 7) direct connections to all major ISP's and NAPs. 

Production Systems 

Production Systems belong to content distributors. It is their decision on how to centralize or distribute this 
function. It is assumed that initially, while the volume of EMD content is relatively small, there will be 
only one Production System per distributor. It is also assumed that the Production Systems will coordinate 
the offers with the Retail Web Sites and will supply all the EMD objects to the distribution infrastructure, 
including the Content Catalog and the Reference and Delivery Services of this distributor. 



t 




Retail Web Sites 

Retail Web Sites belong to the retailers. It is their decision on how to centralize or distribute this function. 
It is assumed that the Retail Web Sites will coordinate their offers with the Production Systems of 
participating distributors and will receive from them the appropriate HTML references. 

Clearinghouses 

Clearinghouses will have to be "certified" in order to participate in the EMD system. There is no 
restriction on the number of clearinghouses which can participate in the EMD system"; Jftfctically, it is 
assumed that there will be one clearinghouse for each large distributor. It is anticipated that the>economic 
forces will probably drive to a small number of players in the clearing business; V \ 

Supporting Operational Infrastructure /{/ * \, >>.. |f 

/-•'(. \ V % .. Jf 

There will be a number of EMD system functions designed to enable and enhance user experience, such as 
the Deployment Manager to download the player, E-mail and Chat/Buddy x Servers for interaction with other 
users and artists, etc. This infrastructure should be transparent ta the user, i.e., .he/she should not have to 
sign up with multiple mail services. It is assumed here that? jE-mail and Chat/B uddy service functions will 
be centralized, perhaps physically associated with the Content Catalo|t The Deployment Manager 
functions may be physically associated with Clearinghouses: 5 The Customer Care function will include 
both telephonic and on-line customer support. The Network Managemeritsfucntion should provide system- 
wide, integrated view of the EMD and enable effective trouble management. 

\ ;\ % 

Customer Systems >.. .. h 

Customers Systems include EMD applications soft 1 ware/hard ware and its environment, either PC- or CE- 
based. There will be a variety of .customer devices in the field, some always connected, some connected at 
times and some never connected^ < ;/> , \V 1/ 

For more detailed discussion; please see ENID Documents 1.2, 1.3, 1.4. 



Operational Description and R quir ments 



This section summarizes major assumptions about how customers and operational personnel will interact 
with the system. For more detailed discussion please see EMD Documents 1.2.2.1, 1.3.2, 1.4.2, 1.4.3, 1.6 
and, especially, 1.8. 



Deployment Operations 

Include setting up the Content Catalog, Reference and Delivery Services, Deployment Manager(s), 
Electronic Clearinghouses and E-mail and other user services. These operations^ will be subject to strict 
change management and control procedures. Backup, archive and restore processes > will be put;in.place to 
ensure reliable operation. W> 

,4 r s '" v ^Ck Ml 
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Production Operations % %,.. % "%f 

Prior to customer transactions, the EMD system has to be "loaded" with the appropriate content and 
information. Production Operations include producing the content (the content herejis defined broadly, 
meaning the content itself and its attributes and rights) for EMD distri%tion, staging content in the 
Distribution Infrastructure (Content Catalog, Reference Service, Deli ver^ery ice). Defining the Reference 
Process - how the Reference Service resolves imprecise queries - also falls in this category. 

Distributor's Production Service (the Production Systems and the people operating it) will format a 
recording (Track) for electronic distribution^; Authorized re^ be informed that this recording is 

available for EMD. Retailers log onto the Production Systems^ via secure extranet and fill out a form 
specifying their "business rules" for this recqrding;|^rule-based tool will be required to manage offers 
definition on-line, as specified imthe^rules table^As the rjsult of this process, the EMD Production 
Systems create a number of content-ass w ated -obj ects : ContentDescription Object, BusinessRules Object, 
Rendition Object and Traek>Object, eacft with a unique ID. If the Track is also a part of a Group (e.g., an 
Album), a Track Group objecSlis also defined together with its ContentDescription, BusinessRules and 
Rendition objects. Production Systems also generate an HTML Reference for each retailer's offer and 
provide it to the retailer. Additiohkt information (e.g., graphics, text, a portion of a web page) might also 
be provided. The recording together witMhe associated objects is secured for the Internet distribution and 
transferred to the Distribution Infrastructure using defined messaging formats. 

By the end of the process different modules of the system have the following information about this Track: 



ArchitectiiralModule 


<f Information 


Content Catalog, 


ContentDescription object 


Reference Service > y 


ContentDescription object, BusinessRules object, HTML reference 


Delivery Service^ " 


Track object, ContentDescription, Business Rules and Rendition objects 


Retail Web Site 


HTML reference 



Use Operations 



This set of scenarios addresses customer's interaction with the EMD system. It includes such functions as 
downloading the enabling software, establishing transactional account(s), finding and downloading content, 



receiving content from other customers, using e-mail, etc. An illustrative brief description of the most 
common user operations is provided here. 

If a customer sees a product (content plus offer) she is interested in on a retail web site, she clicks on the 
HTML Reference and is taken to the specified (in the HTML Reference) Reference Service. The Reference 
Service verifies that the request came from an authorized retailer and that the offer is valid and sends a 
request to its Delivery Service to find the content and the associated objects and to send them to the 
customer. The Delivery Service checks its database, finds where the content is stored and chooses the 
server to download the objects. The selected server initiates an ftp session with the UMP. The customer is 
offered information of the size of the download and the time it will take. The customer will have an option 
to stop the transfer or to schedule it for a later time. Otherwise, the Track and the associatedobjects are 
downloaded to the customer's UMP. When the customer tries to open the content^the protectee! processing 
environment application initiates the rights transaction process as the result ofcwhich the customer, will 
acquire the rights to the content. The transaction will be logged in the Electronic Ciearinghouse'Systems. 

If the customer initiates a query for recordings by an "artist" via the prid function of the^JMP, srie is 
connected to the Content Catalog. The Content Catalog checks its database of Gontentpescrirjtion objects 
using the index "artist" and finds and ranks those that meet the cnteria. If the customer selects one of the 
choices offered by the Content Catalog, she is connected to therReference Service associated with the 
chosen object. The Reference Service searches the Reference Database for offers \vhich include the 
selected content and provides the customer with a choice of offers an^their brief description. If the 
customer chooses one of the offers, the Reference Service'will send a request to trie Delivery Service. 

Settlement Operations % , V 

I 

Content in the EMD system will be distributed in secure containerspwith the "rights" (business rules for 
consuming the content) enclosed. For the most part the transaction for the content will not happen until the 
user decides to consume the content (although transaction can happen prior to consumption - for example, 
in case of off-line CE devices the content wilCbe p^fbratretail and the "rights" will allow consumption). 
When consumer decides to usVthe-dbwnlpad EMD player will interact with the Rights 

Management Software and the user profile; to determine how the content can be used and at what price. 
The system should be.capab%of calculating transaction charges based on the combination of business 
rights, user-specific data . (e.g.; home location^ credentials of belonging to a certain group) and usage (e.g., 
for volume discounts). Periodically, or as. dictated by business rules and budget limitations, the EMD 
player will initiate a. session with thefClearinghouse to report the accumulated transactions. 
\£- /^'^ %. S/ 

Since each cbntent object is securely bound to its rights, Clearinghouses don't have to know the rights in 
order to collect the transactional^iriformation. However, it might be useful for Clearinghouses to know 
some of the rights in distribution in order to detect possible tampering attempts. 

The Player -Clearinghouse communication requires highly secure environment. The Clearinghouse will 
interface to the designated financial institutions to report transactions and, if required to authorize a 
transaction on-line. If necessary, the Clearinghouse will aggregate small transactions for reporting 
purposes. The Clearinghouse shall have the ability to support multiple exchange rates and provide tax 
calculations for variable rates and several taxation levels for all jurisdictions which exist within the 
Clearinghouse's marketing area. The Clearinghouse will maintain extensive audit trails and will be able to 
initiate customer "cancellation" (via the Deployment Manager) if necessary. The Clearinghouse will 
produce financial and usage statements and send them to the content distributors in a specified format. It 
is currently anticipated that the actual customer billing will be provided by financial institutions. 



Network Management Operations 



System Management Operations 



It is assumed that an automated system management tool will be used for on-line monitoring and real-time 
management of the distributor- wideEMD system and its components. The system management tool should 
be capable of: 

remote monitoring and management of system's elements with automatic probjem. detection, 
alerting and alarm escalation, cause analysis ' ^ : ^\ 

automated backup, archive and restore solutions for the key elements^ the EMD 



ability to backup in a live continuously available environment 
performance monitoring and asset management ^ ' ' ^ ^% 

automating configuration and deployment tasks including global distribution 
automatic preventive and corrective actions and prioritiza^i6ri^|iactio^3tems 
central policy-based configuration 
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plugging in 3 rd party monitors, etc. 



It is assumed that the system management tool will be based -on a standard network management protocol, 
such as SNMP, and that various hardware and software components wifflbe required to be compatible with 
this sta ndard. It is anticipated that system management use a commerciaWpff-fhe-shelf (COTS) product, 
such as HH^^^IHIH^^HI^^^^H^^HH or a combinatibn of them. Although different 
portions of the EMD system might be outsourced to /; implemented by different vendors, there needs to be 
an integrated, single point of access to the data affecting dljstributorjs network. 

Security Policy \^%^ 

EMD deployment requires'developmeht of a security policy governing user access to data and applications 
and designed to protect both the system's integrity and the un-secured content. This will be an 
administrative task of net worll operations, including definition of user ID's, groups and roles, assignment 
of access rights by user or group^audit trails?of user and access data, password protection, remote access 
control, virus checking and removal^ etc. / 

Player Management % ' 

J^f ^vC^A N$f&.. --:*V 
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Each EMD player and its secure processing environment will be uniquely identified. The EMD system 
shall maintain- database(s) of deployed players, detailing their unique ID's, version, current status, home 
location, etc^ JThese databases are likely to be located at the Deployment Manager(s) and/or Financial 
Clearinghouse(s). V ../> 

V;-. 

Problem Resolution 



The EMD system shall have one or more focal points for the reporting and correction of service problems, 
closely related to network management and customer care functions. All the reported problems will be 
ticketed and addressed for resolution. Potential COTS products can be considered (e.g., by Vantive, 
Clarify, Scopus) based on scalability, platform requirements, license fees, trouble tracking, customizable 
workflow, sales/web interface, API support, etc. 



Deploym nt Requirements 

This section summarizes major assumptions about sizing, scoping and deployment plans. It defines a high- 
level roadmap / staged rollout plan showing how EMD development is transformed and rolled out to 
become a commercial, mass-market EMD system. For more detailed discussion please see EMD 
Documents 2.1 and 2.2. 



Pilot 



assumed that the EMD pilot ^^^fl^^^HHI^^^^^^^^^^^^^^l- This ; is largely a 
"proof-of-concept" testing stage. The purpose of the pilot is to prove some of the^technoldgy elements, to 
test the basic EMD concepts with users and partners, and to support the development. There is no 
"compatibility" requirement for the pilot (i.e., it can be a "throw away" implementation) and there expected 
to be multiple upgrades/releases during the pilot itself. The pilot is expected to involve some script-based 
testing. y'\ \ \\ J/ 

The content for the pilot will be limited: initially about 20 albums"ahd20 singles, growing to'50 albums 
and 50 singles. The pilot will involve one distributor (UMG),/2t3 retailers, onp provider.bf the distribution 
infrastructure (one content catalog, one reference server, 1-2 deliver y^ser vers), one secure technology 
provider and one clearinghouse provider. j \ ^ \^-\ ^ 



It is expected that the pilot will utilize the secure containers 




The pilot will start with only the basic player functionsjTind content] download content, purchase content, 
create an edit list, etc.) and with limited set^qf content rigntS;(pay5to-own, pay-to-use). The pilot will not 
use real $$'s. v\ ^"v?" ^ . 



It is expected that the pilot will start: with U P to^OO users,and will eventually grow to up to 1000 users. 
Pilot users will be selected to utilize different communications technologies (dial-up, cable modem, DSL). 



Appendix A discusses pilot implementation in greater detail. 



Limited CommercialSTestiriglx # 

^.p, , 1;./ 

It is assumed lhat the EMD limited; commercial ("beta") testing | 

The purpose of the "beta" is to prove the remaining technology elements, to test the more 
advanced EMD concepts witlvusers and partners, to scale up the system, to prove the system operationally, 
and to support ^ the onf going 'commercialization of the EMD technology. There expected to be upgrades 
during the "beta", but at some point (probably towards later stages) a "compatibility" requirement will be 
imposed. v : 

The content for the "beta" will be initially about 50 albums and 50 singles, growing to 200 albums and 200 
singles. The "beta" may involve more than one distributor, 3-5 retailers, one provider of the distribution 
infrastructure (one content catalog, two or more reference servers, 5-10 delivery servers, one mail server, 
one "buddy/chat" server), one secure technology provider and one or more clearinghouse providers. 



The "beta" will start with most of the anticipated player functions and with a larger set of content rights. 
The "beta" will not use real $$'s initially, but may switch towards later stages. 



* .* - 



It is expected that the "beta" will start with up to 1,000 users and will eventually grow to up to 10,000 
users. Only PC-based platforms are expected to be utilized. 

Commercial Rollout 

It is assumed that the EMD commercial rollout will occur right after the "beta" testingmHH' By 

this time all the technology elements should have been proven and bug-free and the system scaled up for 
operation with tens of thousands of users. There expected to be upgrades during the system's lifecycle, but 
they will be subject to the "compatibility" requirement. 

The initial content for the commercial rollout is expected to be initially about 250^316^8^^250 singles. 
The commercial rollout is expected to involve multiple distributors and retailersj/bne or more providers of 
the distribution infrastructure (one content catalog, two or more reference servers^i-Q^O deli very ,ser vers, 
one mail server, one "buddy/chat" server), one or more secure technology ; proyiders^and^one or more 
clearinghouse providers. % x \% p' 



App ndix A: EMD Pilot Implementation 

Fig. Al shows a functional diagram of the suggested EMD pilot. 
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Fig. Al: EMD Pilot Functional Diagram 



It is assumed that the pilot will utilize] 
which are shaded in blue and include thel 



, the 



| offering, the elements of 



and can be 



and the DigiB ox secure container^All these components are available in 

adapted for the EMD triahwith some modifications. The rest of the components shown will have to be 
developed, although; not all bfthem will be required to start the trial. 

~\-- : ( V\ ;/ ' 

The selected EMD content elements will be encoded in the chosen EMD formats. The content elements 
may 'include rriusic and associated video, graphics and text. Due to an anticipated small volume of the 
content, content elements will be managed and tracked manually (in the later stages of the EMD system a 
specialized asset management system will be needed). Using the Layout and Modeler tools from 
|^^^^|, the content elements will be arranged for packaging into DigiBoxes. In addition to the content 
itself, the rights/offers information and the rendition data (including EDL play list and associations) will be 
packaged. When retailer(s) join the pilot, their offer(s) will be in cluded and they will be provided with the 
appropriate HTML reference. A number of possible offers from ^^^^^^HIH library will be 
exercised during the pilot. 



The exact structure of the EMD DigiBox will need to be defined more precisely; it is assumed that all the 
rights information will be encrypted, while the actual multimedia content will be interleaved and only some 
of it will be encr ypted. Note that in the pilot the secure containers will be pre-packaged in the Production 
Systems with the tool (which will use the local IRP). In the later stages of the EMD 

system some or all of the packaging may be done in the Delivery Service. 



After the EMD material is prepared, it will be formatted for the EMD (by the Formatter which will need to 
be developed for the pilot) and staged in the Pilot Distribution Infrastructure. The content description will 
be provided to the Content Catalog and the Reference Server, while the business rules (offers) will be sent 
to the Reference Server. It is assumed that these data will not utilize DigiBoxes, but will use secured links 
(e.g., SSL). In the initial pilot implementation the Content Catalog and the Reference Server can be 
combined into a single entity managing multiple directories. The X.500 technology is the assumed choice 
for these directories, e.g., the DXserver from OpenDirectory, Pty Ltd. The DigiBoxes with the content and 
business rules will be sent to the Delivery Servers. Initially, there may be a single Delivery Server; at the 
later stages we anticipate multiple Delivery Servers with the Resource Manager layer above them 
performing load balancing, optimization and multicasting assignments. 

Prior to being able to download the EMD content, the pilot users will have to acquire the applications 
software. The player and the IRP will be downloaded from the Deployment Manager (while it is'shown as 
a separate entity, during the pilot it will probably be collo cated with the FinanciarClearinghouse\(FCH) 
under the ||^|||^HH^^^IHHiBi^H^^^B)- Once the applications software has been 
downloaded, the user can establish an account with FCH . Communication between the player and the FCH 
will utilize DigiBoxes and H^H^HH^^^HH- While will provide a front end for the 

FCH, limited FCH transaction and payment processing capabihties will ha\e to be developed for the pilot. 
It is assumed that the FCH will not be able to connect to the UMG's back-office^systems during the pilot 
(nor is it really necessary); instead, transaction and usage reports* will^be provided Vviaj"sneakernet" in the 
electronic and paper formats. Once an account has been\established^ : %e user can start transacting with the 
EMD system. // ^ ^fe, 

i-i 
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While it is p ossible to start the pilot with a rudimentary player application<based on the modified 

player, it is crucial to start testing the actual EMD player application as soon as possible. Thus, 
it is recommended that a player application.be developed for the pilot. In addition to interacting with the 
FCH and the IRP, the player application should >be able to process. HTML references from the Retail Web 
Sites and from other users, search the Content Catalog for references, receive content via super-distribution, 
request reference resolution from the Reference Se^rver n and"'manage real-time content playback. 

Some assumptions for the pilot configuration: % 

Pilot Production Systems - two (2) 400+ MHz Pentium II PC's with 15+Gb storage each 
Content Catalog /.Reference Server - one (1) 300+ MHz Pentium II PC with 10Gb storage 
Delivery Servers - two or more 400+ ikUz Pentium II PC's with 15+Gb storage 
Resource Manager - one (1)300+ MHz Pentium II PC with 10Gb storage 
Consumer - 200+ MHz Pentium II or Pentium MMX PC with 4Gb storage 
Deployment Manager - one (1) 300+ MHz Pentium II PC with 10Gb storage 
Financial Clearinghouse - one (1) 300+ MHz Pentium II PC with 10Gb storage. 



The critical path elements in the pilot development are (in the order of importance): 1) the player 
development, 2) the clearinghouse development, and 3) the reference process implementation. | 



